Apigee - Open Source API Management im Vergleich

Von: Thomas Bayer
Datum: 25. Jan. 2019
Aktualisiert: 31. Jan. 2019

1 Das Unternehmen

Apigee hieß vor der Umbenennung 2010 urspünglich Sonoa Systems und wurde von Raj Singh und Ravi Chandra gegründet. Der Name Apigee ist ein Wortspiel aus dem Begriff Apogee, was soviel wie "der Punkt, der am weitesten entfernt von der Erde ist" bedeutet.

Die Apigee Corp wurde 2016 von Google für eine Summe von 625 Millionen Dollar übernommen. Das Produkt von Apigee ist die Apigee Edge genannte API Management Plattform. Seit der Übernahme durch Google hat sich auf der Web Seite von Apigee nicht viel verändert. Das Logo ist immer noch das von Apigee, nur unten auf der Webseite findet man einen Hinweis auf Google. Eine Übernahme durch Google ist meist mit der Befürchtung verbunden, dass das Produkt der Firma verschwindet wie dies z.B. bei der Nik Filter Collection der Fall war. Bei Apigee und Google sieht es ganz danach aus, als bliebe das Apigee Produkt dem Markt erhalten.

2 Deployment

Edge ist die API Management Plattform von Apigee, mit der Benutzer, Organisationen, Produkte und APIs angelegt und verwaltet werden können.

Apigee Edge bietet den kompletten Funktionsumfang der Plattform und bietet Funktionen wie API Verwaltung, Monetization und Analytics.

Betrieben werden kann Edge in der Cloud oder lokal on-Premise im eigenen Unternehmen. Microgateways können eine Edge Installation ergänzen.

2.1 Cloud

Die API Management Plattform kann als Software as a Service Angebot in der Cloud betrieben werden. Über die Cloud können auch lokal installierte Microgateways im eigenen Unternehmen verwaltet werden.

Da die Lösung in der Cloud betrieben wird, ist eine Installation nicht nötig. Dafür ist eine kurze Einrichtung in der Cloud notwendig. Nach der Registierung steht Apigee Edge in wenigen Minuten einsatzbereit zur Verfügung. Zum Ausprobieren gibt es einen kostenlosen, eingeschränkten Evaluation Plan. Kommerzielle Pläne sind ab 500 Dollar pro Monat verfügbar.

2.2 Apigee Edge on-Premise

Edge kann auch im eigenen Unternehmen installiert und betrieben werden. Eine Installation besteht aus mehreren Komponenten, die über mehrere Rechner verteilt werden können. Eine Installation besteht u.a. aus den folgenden Komponenten:

Die ca. ein Dutzend Komponenten sind als Pakete für den Red Hat Package Manager verfügbar.

2.3 Microgateway

Das Microgateway hat einen geringeren Funktionsumfang als Apigee Edge ist dafür einfacher zu installieren und hat einen geringeren Footprint. Beispielsweise kann das Gateway im Docker Container betrieben werden. Eine typische Aufgabe des Gateway ist der Schutz eines Backends z.B. mit OAuth2 gegen unberechtigten Zugriff. Das Microgateway kann dazu direkt vor das Backend auch auf dem selben Rechner betrieben werden.

Zum Betrieb benötigt das Microgateway eine Verbindung zu einer Apigee Edge Installation. Das Gateway wird von Edge mit den Konfigurationen von API Proxies und Produkten versorgt. Ein Produkt ist bei Apigee die Zuordnung von APIs zu einem Benutzer. Für die Authentifizierung von Client Anfragen wird das Microgateway von der Edge Installation mit Credentials für das Ausstellen von Tokens versorgt.

Analysedaten kann das Microgateway erheben, aber selbst nicht verarbeiten. Das Microgateway kann die Analysedaten asynchron an einen Apigee Edge Server zum Speichern und Auswerten weitergeben.

Im Prinzip ist das Microgateway ein einfacher HTTP Proxy Server. Eine Manipulation von Anfragen oder Anworten ist mit dem Microgateway nicht möglich. Auf dem Gateway können keine Policies installiert werden. Policies sind Handler, die in den Nachrichtenfluss eingeklinkt werden. Weiter unten kannst du zu den Policies mehr erfahren.

API Traffic kann lokal über das Microgateway geroutet werden ohne den Umweg über die Cloud. Sensible Daten beiben im Unternehmen obwohl das Management der Gateways in der Cloud erfolgen kann.

Für die Bedienung des Gateways gibt es Befehle für die Kommandozeile.

3 Komponenten

Wird Apigee in der Cloud betrieben, dann sind die Komponenten für den Anwender nicht direkt sichtbar. In der Web Oberfläche gibt es aber eine funktionale Gliederung in Entwicklung, Veröffentlichung, Portal und Analyse.

3.1 Entwicklung

APIs können in Minuten über einen Assistenten eingerichtet werden. Je nach Art des APIs fragt der Assistent die notwendigen Einstellungen ab. Apigee bietet für die Realisierung eines APIs die folgenden Möglichkeiten:

• Reverse Proxy
• SOAP Service
• Endpunkt ohne Weiterleitung
• Entpunkt Implementierung mit Node bzw. Javascript

Für die Einrichtung eines Reverse Proxy werden zumindest die folgenden drei Pflichtparameter benötigt:

Nach dem Einrichten eines Proxies kann dessen Verhalten im Develop Bereich erweitert und verändert werden. Der Screenshot unten zeigt eine Visualisierung des Request und Response Flows mit einer Anordnung von Policies. Eine Policy ist ein Interceptor, der in den Nachrichtenfluss eingeklinkt wird und so Nachrichten lesen und manipulieren kann. Im Beispiel ist dies eine Überprüfung von Quotas, das Extrahieren einer Variable und eine JSON nach XML Konvertierung sowie eine Zuweisung.

Abbildung 1: Entwickeln von Proxies durch die Zuordnung und Konfiguration von Policies

Das Verhalten eines APIs wird über die Policies beeinflusst. Es stehen ca. drei Duzend fertige Policies zur Verfügung u.a. für:

• Transformation
  • JSON nach XML
  • XML nach JSON
  • XSLT Transformation
  • Manipulation von Pfad, Header und Body
• Traffic Management
  • Quotas
  • Spike Arrest
• Sonstige
  • Caching
  • SOAP Validierung
  • Javascript Ausführung
  • Erhebung von Statistiken
  • Logging
  • Callouts an andere APIs und Services

Graphisch wird der Fluss der Nachrichten von Policy zu Policy ansprechend dargestellt. Konfiguriert werden die Policies über XML Dokumente. Das Erstellen der XML Konfiguration wird mit Beispielen und Vorlagen erleichtert. Die zugehörige Dokumentation ist gut verlinkt und nur einen Klick entfernt.

Intern wird für die Entscheidung, welcher Flow für die Verarbeitung zuständig ist eine Bedinung verwendet, die beliebig konfiguriert bzw. programmiert werden kann. Daher sind auch Zuordnungen z.B. über Hostname möglich.

Das Listing unten zeit die Konfiguration einer Policy zur Validierung von JSON Web Tokens.

Zum Ausfüllen der XML Lückentexte hätte Apigee dem Benutzer Formulare anbieten können, da Code auf viele Anwender abschreckend wirkt. Dass auf die Formulare verzichtet wurde, kann auch ein Vorteil sein. Die Konfiguration ist flexibler und kann per Copy und Paste aus Beispielen und Vorlagen übernommen werden.

Bei der Entwicklung mit Apigee ist man nicht auf die Web Oberfläche beschränkt. Ein API kann als zip-Archiv auf die lokale Platte heruntergeladen werden. In einer gegliederten Dateistruktur findet man die XML Dateien aus der Oberfläche wieder. Die Dateien können lokal bearbeitet werden und danach als neue Revision wieder in Apigee Edge installiert werden. Für die Installation kann ein Upload oder ein Werkzeug für die Kommandozeile verwendet werden.

Policies können zu einem Shared Flow kombiniert werden, der als eine Art Unterprogramm von anderen Flows aufgerufen werden kann. Damit lassen sich Funktionen leicher strukturieren und die Wiederverwendung wird unterstützt.

3.2 Kommandozeile

Mit dem Kommandozeilenwerkzeug apigeetool können Funktionen in Apigee Edge ferngesteuert und automatisiert werden. Beispielsweise können Produkte, Entwickler, Caches und Konfigurationen verwaltet sowie Proxies installiert werden.

Ein API Proxy kann mit einer Verzeichnisstruktur beschrieben und entwickelt werden. Die Struktur kann folgende Bestandteile enthalten:

• Konfigurationen
• Policies
• XSLT Stylesheets
• JSON Schemas

3.3 Swagger Unterstützung

Swagger bzw. Open API Dokumente können in Apigee Edge importiert und editiert werden. Im Editor wird das Swagger Dokument im JSON anstatt im YAML Format angezeigt. Swagger läßt sich im YAML Format wesentlich besser editieren als im JSON Format. Eine Möglichkeit zur Umstellung habe ich keine gefunden, was aber nicht heißt, dass es das nicht gibt. Swagger Dokumente können ohne Einschränkung mit einem externen Editor gepflegt und in Apigee importiert werden.

Abbildung 2: Integrierter Swagger Editor, leider mit JSON anstatt dem YAML Format

Interessant ist das Generieren von Proxies aus einer Swagger Dokumentation. Erzeugte Proxy enthalten bereits alle Endpunkte aus der Swagger Dokumentation und ersparen so die händische Eingabe. Ein Endpunkt ist hier die Kombination aus Methode und Pfad.

3.4 Transformation

Für die Transformation der Payload von einem Format in ein anderes gibt es die folgenden Policies:

• XML nach JSON
• JSON nach XML
• XSLT ( XML nach Text, XML, HTML, ...)

Eine Policy für die Transformation von JSON nach JSON sucht man vergeblich. Apigee bietet dennoch Möglichkeiten für eine JSON Transformation z.B. mit Javascript oder einer Policy für die Zuweisung von Werten.

Die Umwandlung von JSON Dokumenten ist momentan so gefragt, dass ich mich wundere, dass Apigee dafür keine dedizierte Policy anbietet.

3.5 Tracing

Der Bereich für die Entwicklung enthält eine Tracing Komponente für die Fehlersuche und das Performanz Tuning. Nach der Aktivierung des Tracings werden Nachrichten, Verarbeitungs- und Übertragungszeiten mitgeschnitten. Hotspots, die einen Großteil der Verarbeitungszeit verursachen können mit dem Tracing schnell gefunden und zielgerichtet optimiert werden.

Abbildung 3: Tracing von API Calls

4 Datenmodell

Das Metamodell von Apigee ist etwas komplexer als beim Durchschnitt der API Management Lösungen. Eine Besonderheit ist der Flow, der in anderen Produkten z.B. mit einem Endpoint abgebildet wird. Ein Flow kann zum Beispiel für einen Endpunkt, also für die Kombination von Methode und Pfad eingerichtet werden.

Eine weitere Besonderheit ist die Zuordnung von APIs zu Portalen, die über das Zwischenobjet Produkt erfolgt. Dies ist besonders für die Verwaltung und Gruppierung einer sehr großen Anzahl von APIs nützlich.

Abbildung 4: Datenmodell

5 Developer Portal

Im Portal können APIs veröffentlicht werden. Interessierte Entwickler können im Portal auf Swagger basierende API Beschreibungen finden und haben die Möglichkeit eine Subscription für ein API anzulegen. Eine Subscription ist eine Voraussetzung für die Nutzung eines APIs.

Abbildung 5: API Dokumentation im Developer Portal

Zur Verwaltung des Portals wurde ein kleines Content Management System in Apigee integriert, in dem Seiten, Bilder und Styles verwaltet werden können. Eigene Seiten können im Developer Portal mit Text im Markdown Format erstellt werden.

Abbildung 6: Verwaltung von Bildern im CMS des Portals

Das Aussehen des Portals kann im Theme Editor mit eigenem Logo und Farben angepasst werden. Fortgeschritte Anwender können eigene CSS Styles hinterlegen.

6 Analyse

Unter Analyse findet der Administrator zahlreiche Reports zur Performanz, dem Cache und der Aktivität der Entwickler. Alle Performanzdaten können als CSV Daten exportiert werden.

Das Diagram unten zeigt die Aufrufe pro Minute.

Abbildung 7: API Proxy Performanz: Aufrufe pro Minute

Sollte bei den vorgefertigten Reports nicht der passende dabei sein, dann können mit dem Report Generator eigene Reports angelegt werden.

6.1 Custom Report Generator

Mit dem Report Generator können eigene Reports erstellt werden. Wie aus der Abbildung unten ersichtlich können mit dem Generator nicht nur die Metriken ausgewählt werden, es ist sogar möglich selbst die Gruppierung z.B. nach Dimensionen wie API, Entwickler oder Client selbst zu bestimmten.

Abbildung 8: Custom Report Generator

6.2 Anomalie Erkennung

Ein wenig Data Science hat in das Apigee Produkt Einzug gehalten. Vielleicht ist dies eine Auswirkung des Verkaufs an Google. Die Abbildung unten zeigt ein Diagramm zur Anomalie Erkennung bei den Verzögerungszeiten.

Abbildung 9: Diagram zur Anomalie Erkennung

7 Sicherheit

Die Absicherung eines APIs erfolgt über das Einrichten von Policies. Zur Authentifikation und Authorisierung stehen u.a. die folgenden Policies zur Verfügung:

• OAuth2
• API Keys
• Basic Authentication
• JSON Web Token (JWT)
• SAML

Im Enterprise Umfeld kann die SAML Autentifizierung interessant sein, da SAML noch bei vielen großen Firmen für Single Sign on zum Einsatz kommt.

Ferner gibt es zur Absicherung gegen Denial of Service Attacken eine JSON und eine XML Threat Protection.

Audit und Revisionssicherheit

In einem Audit Log werden alle Aktionen der Benutzer mit Datum aufgezeichnet, so dass jederzeit nachvollzogen werden kann, wer wann was an der Plattform geändert hat.

8 Dokumentation

In der ausführlichen Dokumentation finden sich zahlreiche Beispiele, ein Cookbook mit Patterns und ausführliche Erklärungen. Die Web Oberfläche verlinkt die jeweils relevanten Abschnitte in der Dokumentation und erspart dem Bediener die Suche.

Wer in der Dokumentation nicht fündig wird, der findet bestimmt etwas in der Apigee Developer Community. Dort gibt es bereits zahlreiche Einträge und rege Diskussionen.

Abbildung 10: Apigee Developer Community

9 Preise

Ein kostenloser Testzugang, mit dem entwickelt und Tutorials durchgearbeitet werden können, kann in Minuten ohne eine Kreditkarte eingerichtet werden.

Apigee platziert sein Angebot, wie an den Preisen ersichtlich, im Prämiumsegment. Der günstigste nutzbare Vertrag liegt bei 5.000,- € im Jahr und ist auf 3 Benutzer und 2 Umgebungen limitiert. Bei den Benutzern handelt es sich um Administratoren. Die Anzahl der Entwickler, die ausschließlich die Portale nutzen ist nicht limitiert.

Garantierte Antwortzeiten des Supportes gibt es bei einem Vertrag über 25.000,- € im Jahr. Die Analytics Funktion ist bei diesem Tarif auf die Werte der letzten 90 Tage beschränkt. Erst beim Vertrag ohne Preisangabe gibt es Rückrufe durch den Support und die Berichte zur API Nutzung können die Werte eines ganzen Jahres enthalten.

Die Lösung von Apigee ist interessant und ermöglicht es Unternehmen sich im Rahmen der Digitalisierung zu einer Plattform zu öffnen. Bei einer API Nutzung auf Konzernebene spielt der Preis eine untergeordnete Rolle. Für einzelne Abteilungen oder kleinere Projekte könnte der Preis durchaus eine Hürde sein.

10 Fazit

Das Produkt deckt von der Cloud bis zum lokalen Microgateway alles ab. Die Enticklung kann entweder graphisch in der Cloud oder lokal durchgeführt werden. Der Funktionsumfang ist u.a. mit Tracing und Report Generator beachtlich.

Apigee Edge hebt sich von anderen Produkten durch die Unterstützung der Legacy Technologien XML, XSLT, SOAP und SAML ab. Wird ausschließlich REST und JSON verwendet, geht das mit Apigee ebenfalls ohne Einschränkungen. Sind SOAP basierte Web Services zu integrieren, so bietet Apigee die dafür Policies und Assistenten.

Mit etwas mehr als drei Dutzend Policies bewegt sich Apigee was Funktionalität angeht im Mittelfeld. Dafür bieten die Policies über die XML Konfiguration viele Möglichkeiten, wie z.B. die Assign Message Policy, mit der vom Pfad, über den Header bis zur Payload alles verändert werden kann.

Empfehlung

Apigee ist besonders für Unternehmen geeignet, die ganz auf die Digitalisierung setzen und eine große Anzahl von APIs externen Partnern zur Verfügung stellen möchten.

Vorteile

• Unterstützung für verschiedene Umgebungen (Test/Prod)
• Zahlreiche Assistenten
• Komfortables Tracing für die Performanz Optimierung
• Unterstützung von SOAP, WSDL und SAML
• Versionierung von API Entwicklungsständen
• Ausführliche Dokumentation und große Entwickler Community
• Scripting mit Python
• SAML Unterstützung für die Integration mit Legacy Systemen
• Report Generator, mit dem eigene Reports erstellt werden können
• Anomalie Erkennung

Nachteile

• Reines Cloud Angebot. Eine lokale Installation ist nicht möglich.